東葛.devアドベントカレンダー2025 22日目予定地
まえがき
自分がこれまで関わってきた現場は、いわゆるきれいな教科書通りのプロジェクトではありませんでした。
といった、「アジャイルとウォーターフォールの悪いところ取り」のような進め方になってしまっているケースも少なくありませんでした。→この書き方誤解を招きそう... もちろん、こうした状況は PM やビジネスサイドが怠けているから起きている、とは思っていません。 ビジネスサイドの制約の例
顧客の事情や社内政治
売上目標や契約条件
限られた人員・スケジュール・情報
彼らは彼らで上記のような別種の制約の中、かなりの板挟みになっていることも多い。
むしろ、そうした制約の中で何とか形にしようとしているがゆえに、きれいなプロセスから外れてしまっている、という側面もあると感じています。
この記事で書いているのは、そうした理想的な役割分担やプロセスからは外れてしまっている現場で、 エンジニアとしてどうボトムアップで関われば、少しでもマシな方向にプロジェクトを進められるか、という自分なりのメモです。→戦略ではなく戦術になってる時点で負けてますよねと言われそう... 誰か特定の職種や個人を責めたいわけではなく、
「決まっていないことが多い現場でも、エンジニアとしてこういうスタンスや小技があるとやりやすかった」という経験談として読んでもらえれば嬉しいです。
この記事が同じ境遇の方への参考になれば
※健全な開発プロセスが回っている現場には不要な内容かもしれません
スタンス
確認する＆確認しすぎるとうざがられる確認すべきことを確認する＆確認しすぎてウザいを避ける
要件や業務フローが流動的な現場だと
確認が必要だが、何でもかんでも聞くわけにもいかないというジレンマがあるナイトウ.icon個人的には大事なことなら何回でも確認してもいいと思ってる派です
どうしますかではなく
こちらで仮説をいくつか準備しぶつける
というやり方を意識しています。
最初から正解があるわけではない
業務フローが固まってない
こういう場合、決まっていないことを嘆いたり、攻めたりしても始まらない
相手の中に正解はない→正解と思われるものを汲み取り作って行くor一緒に正解を作る作業と割り切る
そのための材料としてエンジニア側から、仮説、たたき台、選択肢を提示するという感覚
なぜやるかのマインドセット的なところ
エンジニアリング→技術を用いて課題を解決すること
コードを書くことそのものだけがエンジニアリングではないナイトウ.iconいいね
課題解決がエンジニアの本分なので、課題解決に必要なことはやる必要がある（顧客にミーティングで質問するのも、関連する業界の知識をつけるのも、 極論すればファシリするのも議事録取るのもエンジニアリング（課題解決の営みの一部））
（現場によっては余計なことすんなよとかがあるのでそこは壁にぶつかることになると思う）
制約（納期が最優先、金になれば良い）などあるがその中でも自分の矜持として最善を尽くしたいね（言うは易く行うは難し）
有効だった具体的な動き方
たたき台として画像イメージなどをメモ書きでもいいから作る
口頭やテキストだけで議論していても噛み合わないときは、
画面イメージやフロー図の叩きを作るナイトウ.iconたたきを作る人が一番偉大
PowerPoint などにコメントを書き込みながら共有する
といった形に落とし込むと、かなり前に進みやすくなりました。
自分自身も、作っている過程で考えが整理される
相手も、具体物があると「ここが違う」「ここは合っている」とフィードバックしやすい
ので、議論の土台を作るための「叩き」としての成果物は有効だと感じています。
もちろん、場合によっては良いから作れよになる可能性はあるがそれも含めて経験だと割り切るようにしています。
生成AIを「叩き」と「レビュー」に使う
レビューしてくれる人が常にいるとは限らないので、
既存の画面やAPI仕様を渡して、追加機能案を出してもらう
自分の書いた案をレビューしてもらい、漏れや観点を補完する
といった形で、セルフレビュー以外の視点を無理やり取り込むことも増えました。
もちろん、
なぜその案を採用したかやどういう意図やトレードオフがあるか
を説明する責任は自分にありますし、AIの出力をそのまま鵜呑みにすることはできません。
それでも、議論のたたき台を短時間で増やす武器としてはかなり使えます。
コミュニケーションのトーンについて
敵ではなく一緒に作る仲間だと言うことをスタンスをとる
Biz サイドや PdM / PdO に対しては、
「あなたの敵ではなく、一緒に良いものを作っていきたい立場です」
というスタンスを、言葉や文体から伝えられるように意識しています。
相手の前提を尊重してコミュニケーションしようと意識するだけでも、
不必要な衝突はかなり避けられると感じています。
文体に感情を乗せすぎない
自戒ですが、走り書きで Slack やチケットを書くと、
フラストレーションがそのまま文章に乗る
Biz 側から見ると「敵対的」「責められている」と感じられる
ことがあります。
自分としてはそこまで強い意図がなくても、「トゲのあるエンジニア」に見えてしまうと、
進むものも進まなくなるので、感情が動いているときは一呼吸おく
「なぜ困っているのか」「何が不確かで判断が難しいのか」を、攻撃的にならないように書く
というあたりは、かなり意識して修正するようになりました。
仕様は誰が決める？
「なんで仕様が決まってないんだ」
「業務フローが固まってないのにどうするんだ」
と思ってしまうこと自体は、自然な反応だと思います。
自分も何度もそう感じました。
ただ、経験上、そこに長くとどまっても、プロジェクトは一ミリも前に進まないので、
「なぜ決まっていないのか」「決められない背景は何か」をできる範囲で理解しつつ
その前提条件の中で、「では今できる一歩目は何か？」に切り替えるしかない、という感覚に落ち着いています。ナイトウ.iconすごすぎ
まとめ
自分は経験を通じて、エンジニアの本分は課題解決であり、
課題解決に必要なことであれば、可能な範囲で手を伸ばしていくべきと思うようになってきました（良い悪いの話ではない）
もちろん、現場ごとの役割分担、契約や責任範囲、組織文化
といった制約はありますし、「何でもやればいい」という話ではありません。
それでも、
仮説を自分から出す
叩きの成果物をつくる
生成AIやツールを活用して視点を増やす
相手を敵にしないコミュニケーションを心がける
といった、現場からのボトムアップの動きは、
きれいな道ではなく、あぜ道を爆走するようなやんちゃな現場「理想的なプロセスから外れてしまっている現場」ほど価値が出やすいと感じています。
この文章がモヤモヤしながらも、それでも何とか前に進めようとしているエンジニアの方の参考になれば嬉しいです。